Realtime test result promulgation from network component test device

ABSTRACT

The technology disclosed relates to real-time collection and flexible reporting of test data. In particular, it is useful when collecting packet counts during tests of network devices that simulate thousands or even millions of data sessions conducted through a device under test (“DUT”).

RELATED APPLICATION

This application is a continuation application of U.S. application Ser.No. 13/118,843, filed 31 May 2011, entitled “REALTIME TEST RESULTPROMULGATION FROM NETWORK COMPONENT TEST DEVICE,” by inventors BrianSilverman, Thomas R. McBeath, Abhitesh Kastuar, and Sergey Rathon, nowU.S. Pat. No. 8,533,524, issued 10 Sep. 2013.

This application is a continuation application of U.S. application Ser.No. 12/130,963, filed 30 May 2008, entitled “REALTIME TEST RESULTPROMULGATION FROM NETWORK COMPONENT TEST DEVICE,” by inventors BrianSilverman, Abhitesh Kastuar, Thomas R. McBeath and Sergey Rathon, nowU.S. Pat. No. 7,958,387, issued 7 Jun. 2011.

This application is related to U.S. patent application Ser. No.12/130,944, filed 30 May 2008, entitled “METHOD AND DEVICE USING TESTDATA STREAMS BOUND TO EMULATED DEVICES,” by inventors Abhitesh Kastuar,Jan-Michael Kho and KaChon Lei, now U.S. Pat. No. 7,826,381, issued 2Nov. 2010.

This application is also related to U.S. patent application Ser. No.12/130,854, filed 30 May 2008, entitled “METHOD AND APPARATUS FOREMULATING NETWORK DEVICES,” by inventor David Joyner, now U.S. Pat. No.8,264,972, issued 11 Sep. 2012. The related applications areincorporated by reference.

BACKGROUND OF THE INVENTION

The technology disclosed relates to real-time collection and flexiblereporting of test data. In particular, it is useful when collectingpacket counts during tests of network devices that simulate thousands oreven millions of data sessions conducted through a device under test(“DUT”).

The Internet and backbone networks handle a very large volume of datatraffic. The routers and switches that handle these volumes of data aremuch different from the equipment that ordinary people have in theirhomes. While the names are the same, the capacities and protocols aremuch different.

In addition to backbone infrastructure, so called triple playinfrastructure is being deployed at a local level. Triple playinfrastructure involves high volumes of data, because it delivers voice,data and HDTV services into homes, typically using a single physicalchannel. Both scheduled, broadcast HDTV and HDTV on-demand have thepotential of creating packet loads that far exceed the data demands ofeven the most ambitious websurfer.

During development and prior to deployment, it is useful to test highcapacity routers, switches and hybrid devices. Testing is particularlyimportant as new features are added and old features are enhanced. Manyalternative protocols exist for carrying packets from one point toanother. The more alternative protocols a device attempts toaccommodate, the greater the likelihood of unpredicted interactions.

Regression testing is one tool for making sure that new features do notbreak existing components. In regression testing, previously run-testsare repeated to assure that new functions have been implemented withoutimpairing old ones. Elaborate scripts are often developed for regressiontesting.

During development and prior to deployment, conformance, functional,performance and passive testing may be conducted. Conformance testingallows developers to verify that the operation of their device conformsto established, industry-accepted standards, conventions, or rules, suchas RFCs or draft standards. During functional testing, developers verifythat the device does everything that it has been designed to do,including protocol support, filtering, and management functions.Performance testing provides information about levels of performance,such as throughput, frame loss, latency, route pairing, or scalability.This approach includes stress testing to show how a device behaves underload conditions. In addition, passive testing can be performed toanalyze protocol performance, either intrusively or non-intrusively.

A test device that stresses a core router, for instance, may include adozen or more interfaces that operate at 10 or 40 gigabits. In testconfigurations for backbone core routers or interconnect switch fabrics,multiple test devices may be combined into a single test system thatgenerates an enormous amount of test data.

It is difficult or impossible, using conventional data processingapproaches, to respond to data queries in real time, during a test. Atthe end of a test, it can take hours to collect test sample data andmarshal it into a database.

An opportunity arises to introduce a new data collection anddistribution architecture that is adapted to test devices. Better, moretimely and more responsive testing may result, with significant benefitsto those who develop and deploy high-volume routers and switches.

SUMMARY OF THE INVENTION

The technology disclosed relates to real-time collection and flexiblereporting of test data. In particular, it is useful when collectingpacket counts during tests of network devices, such as stress tests thatsimulate thousands or even millions of data sessions conducted through adevice under test (DUT). Particular aspects of the present invention aredescribed in the claims, specification and drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a line drawing of a Spirent™ SPT-9000A test chassis.

FIG. 2 is a high-level block diagram of some physical and logicalentities that combined as a test device.

FIG. 3 is a high-level block diagram of a test device coupled to a DUT,with emphasis on configuration of stream blocks.

FIG. 4 is a high-level block diagram of a test device, with emphasis onsoftware modules at levels of management logic and processing cardlogic.

FIG. 5 is a high-level block diagram, with emphasis on instantiation ofmultiple databases.

FIG. 6 is a block diagram of that features the analyzer daemon as thecentral component.

FIG. 7 is a more detailed block diagram of the interaction of theanalyzer daemon with the stats framework.

FIG. 8 is a block diagram that provides more detail of one embodiment ofthe analyzer driver.

FIG. 9 is a more detailed block diagram of the Stats Framework.

DETAILED DESCRIPTION

The following detailed description is made with reference to thefigures. Preferred embodiments are described to illustrate the presentinvention, not to limit its scope, which is defined by the claims. Thoseof ordinary skill in the art will recognize a variety of equivalentvariations on the description that follows.

FIG. 1 is a line drawing of a Spirent™ SPT-9000A test chassis. TheSpirent TestCenter SPT-9000A is one in a family of network test systems.Other members include the SPT-5000A, a high density network performancetest system and the portable SPT-2000A/HS. Among this family, theSPT-9000A is the very high density test member typically used in the labor a production test environment.

This test device is highly suitable, where high density Ethernet portsare desired for high-volume production and large port count testing.This test device has 12 vertical slots that can support a variety ofconfigurations. For instance, the chassis can be filled with up to 14410/100/1000 Mb per second Ethernet ports. Or, it can be filled with 144fiber or dual media gigabit Ethernet ports. It can support up to 2410-gigabit Ethernet ports, 24 UniPHY (10 GbE/OC-192 POS) ports, 24 WANOC-48/12/3 POS ports or 24 10 GBASE-T ports. It is anticipated that 40GbE and 100 GbE ports also will be supported, as testing requirementsrise. FIG. 1 depicts a mix of these port types.

The Spirent TestCenter™ is one example of integrated performanceanalysis and service assurance systems that enable the development anddeployment of next-generation networking technology, such as Internettelephony, broadband services, 3G wireless, global navigation satellitesystems and network security equipment. The technology described in thisdisclosure applies to Spirent TestCenter™ products and generally to IPperformance test systems and service verification platforms for IP-basedinfrastructure and services. This technology is useful in systems thattest and validate performance and scalability characteristics ofnext-generation networking technology for voice, video and dataservices. Test devices, using the technology disclosed, are useful tonetwork and telephony equipment manufacturers, semiconductormanufacturers, service providers, government departments, andenterprises to validate the capabilities and reliabilities of complex IPnetworks, devices and applications, such as networks for delivery oftriple play packages that include voice, and video and data services.The technology disclosed is useful in testing both control plane anddata plane traffic.

FIG. 2 is a high-level block diagram of some physical and logicalentities that combined as a test device. The test device may include oneor more chassis. Multiple chassis 201, such as the SPT-9000A, cancommunicate among themselves to conduct a test with a large number ofports. As illustrated, a chassis may include multiple processor cards203 and each card may support multiple ports 207. At a logical testlevel, a variety of device types can be emulated at a port. An emulateddevice has a variety of configurable characteristics 209, such asnetwork connectivity characteristics, host features and interfaces.Emulated devices and their configuration are more fully described in thecontext of FIG. 3, below. Test streams 211 are coupled to emulateddevices and their configured characteristics. Multiple streams of testdata can be associated with a pair of test devices. A stream of testdata may be configured to represent a multiplicity of sessions whereeach session is called a flow. A flow represents a network useraccessing network services such as a server on the Internet,peer-to-peer communications with another user, etc. Each network userwould have her own Ethernet MAC Address and IP Address. The users' IPaddresses might be dynamically configured. In some embodiments of thetest device, streams and flows are differentiated primarily by thegranularity of test data collection. In this embodiment, separate banksof counters are maintained for keeping track of each stream, butindividual flows within a stream are not separately tracked.

The logical hierarchy of elements depicted in FIG. 2 supports flexiblescaling of tests. A small chassis with one or two cards can test arelatively small router or switch. Or, a cluster of chassis can becombined to test a very powerful backbone core router or switch. Withthis background, general outlines of an innovative distributed databasewithin a chassis can be described.

Prior to implementing the technology described below, it could takehours to download test statistics, from one or more high-volume chassis,at the end of a test. The prior strategy was very direct. A managementlevel application would directly query processes running on theprocessing cards of the chassis. The processing cards would return allof the data that they had collected. The management application wouldsuccessively send queries and receive results from all the processingcards involved. Data received would be encapsulated in objects. Theobjects would be passed to a database adapter and the database would beupdated.

In one embodiment, this innovative approach adds a distributed databaselayer running on each processing card, with multiple instantiations ofdatabases, including tables and database access software, per processingcard. It is surprising that adding a database processing layer couldspeed up the collection of test data, at the end of a test and enablesreal-time reporting during a test. Ordinarily, one would expect thatadding an additional, intermediate database software layer would onlyslow things down. It is further surprising that instantiating multipleinstances of databases per processor, again including tables anddatabase access software, could be efficient. In testing, the innovativeapproach that we disclose has dramatically reduced the time required tocollect end-of-test results by about two orders of magnitude, from hoursto minutes.

The databases are embedded, in-memory databases that have bothproprietary API and SQL interfaces. A data collection routine retrievesstatistics from counters with a predetermined or programmed resolution,such as every second or 10th of a second. The data collection routineuses the database API to add rows of sampled values to database tables.In one embodiment, there is a separate database instantiated for eachport on each processing card. Different types of traffic on the port canbe maintained in different tables. In a high resolution mode, datacollection in limited domains may be as frequent as every millisecond orevery 100^(th) of a second, as specified by a user.

It is surprising that numerous in-memory databases can be practicallymanaged with better performance than fewer databases. In practice, useof numerous databases with simple table structures and transactions thatrequire minimal locking has provided strong performance.

It is further surprising that using numerous databases with SQL queryinterfaces works well. The eXtremeDB™ embedded in-memory database has anSQL interface (eXtremeSQL™) and is commercially available from McObjectat www.mcobject.com. The SQL interface is fast and efficient enough tobe used for real time queries during a test.

Overall, surprisingly good results have been achieved by the approachdisclosed, despite introduction of a new database layer between themanagement application and the counters maintained by hardware, despiteusing multiple instantiations of databases per processor, and despiteusing SQL queries for data retrieval. Nearly a hundred-fold improvementin end-of-test data retrieval has been achieved and real time reportingcan be realized.

FIG. 3 is a high-level block diagram of a test device coupled to a DUT,with emphasis on configuration of stream blocks. FIG. 3 generallydepicts a two port test with test packets moving from port one throughthe DUT to port two. On logical port one (320), in this example, theemulated ingress device 321 is a router. It might alternatively be aswitch or a hybrid device. In this example, including the MPLS protocol,it is coupled to network connectivity object 323 and a stack ofinterface definition objects 324, 325, 326. The network connectivityobject is a Label Distribution Protocol (LDP) router configuration 323,which relates to the MPLS interface 325. The interface stack depictedincludes IP (324), MPLS (325) and Ethernet/MAC address (326) objects.The network connectivity and interface stack objects publish their datato an observer that is part of the stream block object 322. The streamblock object 322 corresponds to data streams that will be generated onport one (320), which is attached to an ingress port of the DUT. Thestream block object 322 subscribes to or observes data initiallyconfigured and later updated on the network connectivity and interfaceobjects. Binding the stream block 322 to a source emulated object setsup a so-called observer pattern, as does binding the stream block to adestination emulated object. On port two (330), the emulated egressdevice 331 of this example also is a router. In other examples, it couldbe a switch or a hybrid device. The network connectivity objects andinterface objects connected to the router 331 include an LDP routerconfiguration 333 and Label Switching Protocol (LSP) information 335.These are network connectivity and interface objects for a downstreamdevice that uses the MPLS label-based switching and routing protocol.When an MPLS session is initiated, the LDP generates LSP information,which is distributed from the downstream router, through the DUT to theupstream router. The configuration objects at the BLL layer for theports 320, 330 are in communication with so-called firmware at the ILlayer. This firmware is more closely coupled to the physical ports ofthe test device than the BLL. In the upstream position, theconfiguration objects are in communication with the routing daemon 341and a generator 343. The routing daemon, depicted here as a singledaemon, may actually be implemented as a series of routing daemons forvarious protocols. The routing daemons may generate and/or receiverouting address information. For instance, in a DHCP implementation,routing daemon 341 may listen for updated IP address information as DHCPleases expire. When the routing daemon detects new address information,it publishes that information to other components. In one embodiment,the stream block or IP configuration object observes, listens to, orreceives messages from the routing daemon with updated IP addressinformation. Then, the generator 343 may observe the stream block 322for updated IP information. In another embodiment, updated routinginformation may be directly forwarded from the routing daemon to thegenerator at the IL layer, as well is being published for the BLLobjects to update themselves. At the firmware layer, the protocolsillustrated in FIG. 3 use the routing daemon 351 on IL layer port two350 and test result analysis relies on the analyzer 353.

In this testing configuration, only one stream block is depicted,corresponding to packets traveling from port one to port two. In actualtesting, packets may be generated on each of the ports and sent back andforth. Then, two or more stream blocks would be used. In general,high-volume testing uses stateless generation of test packets. That is,packets generated for port one depend on address or control planeinformation that identifies port two sufficiently for routing, but donot follow a request-and-response model on the data plane. The dataplane traffic is stateless.

We refer to stream block 322 as a bound stream block, in contrast to theraw stream blocks of earlier products. A bound stream block has sourceand destination bindings. From the bindings, the stream block learnsboth static information used to construct a prototype test frame or testpackets and dynamic address information that is generated by operationof the control plane. The process for learning information, using theobserver pattern, involves different data and program structures thanthe old approach of using a wizard to add the same data to differentdata structures. The observer pattern has the additional advantage thatit updates dynamic address information during a test, which is a naturalpart of many test scenarios. Address updates are dynamically propagatedand quickly reflected in test packet traffic. Other processes forlearning information, such as inter-process communications via pipes,could be used instead of following the observer model.

FIG. 4 is a high-level block diagram of a test device, with emphasis onsoftware modules at levels of management logic and processing cardlogic. The management logic 410 in this embodiment runs on a separatecomputer coupled in communication with a chassis that holds processingcards 440. For instance, the management logic can run on a laptop,desktop or workstation. Alternatively, the chassis of the test devicecould have a built-in processor and other resources, or the chassis,could accept a processor card that would run the management logic. Then,a terminal or monitor could be coupled to the chassis to manage datacollection. The processing card logic of this embodiment, sometimescalled firmware, includes components running on a general purpose CPU450, and components implemented in an FPGA 470, are sometimes calledhardware. As compared to FIG. 3, this figure reveals more of the modularprogramming structure and less of the data structure.

The management logic 410 includes a framework 420 and components forrouting 431, layer 2/layer 3 tests frame generation 435, and a DHCP host437. The framework is where the emulated devices 421A, 421B and theirinterfaces 422A, 422B are modeled. These emulated devices are comparableto 321, 331 in FIG. 3. The interfaces are comparable to 324, 325, 326.The routing component 431 depicts support for two routing protocols,label LDP 432 (see, e.g., RFC 5036) and Border Gateway Protocol (BGP)433 (see, e.g., RFC 4271). The routing component supports a variety ofrouting protocols and may use separate subcomponents or daemons to doso. The routing component is responsible for setting up IP routing viathe DUT. The layer 2/layer 3 component 435 includes bound stream blocks436 that define test frames. A bound stream block is bound to an ingressdevice 421A and an egress device 421B. It may be updated with routinginformation through one of the emulated devices or directly from therouting component. This figure adds a DHCP component 437 that supports aDHCP session 438. For instance, the emulated egress device, 421B, mayserve as a DHCP client and receive its address from a DHCP host. Routingcomponent 431 has a counterpart routing component 451. Stream blockcomponent 436 has counterpart generator 455 and analyzer 456 componentsfor the ingress and egress functions on a test, respectively. DHCPcomponent 437 has a corresponding DHCP component 457. The routing,generator, analyzer, and DHCP components running on the processor areimplemented, in one embodiment, by respective daemons per processingcard. A large number of emulated devices and their interfaces on theprocessing card can be handled by a single routing component 451 and asingle DHCP component 457. Alternatively, additional routing componentsand DHCP components could be allocated. The component IfMgr 416 is aninternal object that manages network interfaces and validation ofinterfaces. The IfMgr, routing component, and host component interactwith the Linux kernel. The routing and host components generate controlplane packets that the Linux kernel processes. The generator 455 andanalyzer 456 components operate in the data plane of the ingress portand egress port, respectively. They process test descriptions availablefrom the interfaces bound to the stream block 436. In some embodiments,routing information learned at the routing daemon 451 may be passeddirectly to the generator daemon 455 in addition to being propagatedupwards to the management logic 410. The generator and analyzer demonsinteract with the streams components 473 of the FPGA.

On the FPGA 470 control plane data is handled by a cut through FIFO 471that interacts with PHY, which schedules transmission of the controlplane packets across the port 474. A cut through FIFO is appropriatebecause the FPGA processing of control plane packets is minimal. On theother hand, data plane test frames and packets are the primary reasonfor use of an FPGA. Details of the FPGA streams components 473 arebeyond the scope of this disclosure. The streams components 473 buildtest frames to be sent across PHY 472 and the port number 474 andprocesses test frames received across these components.

Overall, from FIG. 4, one sees architectural detail around which thedatabase instantiations, depicted in FIG. 5, are organized.

FIG. 5 is a high-level block diagram, with emphasis on instantiation ofmultiple databases. On the processing card 440 the message handlingcomponent 562 and the multiple instantiations of databases 559 are newto this figure. Other components of the processing card includinginterfaces 422, routes 432, stream blocks 436 and the instrument layergenerator and analyzer 470, which retain their reference numbers fromthe prior figure. The chassis 520 includes one or more processing cards440. Alternatively, a server or cluster of servers could includeprocessors and, to whatever extent necessary, specialized logicprocessors. Workstations or PCs might be substituted for servers. Thechassis includes a least one communications channel for coupling theprocessing cards to management logic.

The management logic is again represented by the BLL 410. In thisfigure, the BLL is coupled in communication with the graphic userinterface (GUI) 511, and a persistent database 515. It includes avariety of components that are further described below. The graphic userinterface may accept configuration data for emulated devices, interfacesand routing. It may accept test requirements for stream blocks. During atest, it may accept query requests and return test data sample results.At the end of the test, it may accept a command to retrieve and persistall test data and may display results from persisting the data. Thepersistent database 515, unlike the in-memory databases 559, is limitedby channel characteristics of persistent memory. For instance, thechannel and rotating media characteristics impact the performance of adisk drive used as persistent memory. Alternatively, an optical memoryor non-rotating memory could be used. At present, the disk drive is themost favorably priced high speed access device for large volumes of testdata.

The processing card 450 includes at least one processor 551 andsolid-state memory 553 coupled in communication with the processor,which provide resources for operation of the logic. The processing cardincludes two or more ports 340, 350, 474 that are adapted to be coupledto a device under test 313.

Distributed logic running on the processing cards includes a pluralityof database instances. As explained above, eXtremeDB™ is a suitable inmemory database. In a typical test with a dozen or more ports, numerousdatabase instances may run on one or more processing cards. In oneembodiment, the number of database instances will be one per port, withvarious tables for various types of data. A separate database instancecould be instantiated for each port and each protocol handling objectassociated with each port, so that different sample data statisticsapplicable to different protocols are stored in different databaseinstances. With finer granularity, the test may be organized into aplurality of test data streams that emulate a multiplicity of datasessions. Database instances may be instantiated per port and per testdata stream. Or, they may be instantiated per port, per protocolhandling object (for network connectivity and interfaces) and per testdata stream.

In one of the alternative embodiments, a plurality of database instancesrun on a particular processing card to support a corresponding pluralityof ports. Database instances support different tables for differentprotocol handling objects or for different categories of information.Instead of having a separate database instance each protocol supportedby the port, there may be a separate table within a database instanceassociated with a port. Similarly, the number of database instances maybe reduced by including a stream number in each table row and storingtest data samples from multiple inbound streams in a single table. Thisalternative may be used with separate database instances for differentprotocol handling objects or it may be combined with use of differenttables for different protocol handling objects, within a single databaseinstance for the port.

In FIG. 5, the BLL 410 includes a data selection component 512 thattranslates user requests into queries for responsive data. It alsoincludes a messaging component 514 that identifies a plurality ofdatabase instances to which queries should be addressed. The messagingcomponent 514 sends the query is to the identified database instances.In one embodiment, a particular query is sent in a series of unicastmessages, one per database instance from which data is requested.Alternatively, a multicast-like messaging scheme could be developed toreduce the number of messages. Preferably, the messaging component sendsout successive queries to successive database instances without waitingfor responses. Then, it receives responses in parallel as they becomeavailable, without waiting for completion of database operations. TheBLL 410 further includes a response segregation component 516 thatcombines the selected sample data from the responses and an outputcomponent 518 that either persists the combined data in the persistentdatabase 515 or makes the combined data in some form perceptible to theuser, for instance via the GUI 511.

FIG. 6 is a block diagram of that features the analyzer daemon as thecentral component. The analyzer daemon 353 consists of an upper firmwareapplication layer 630 and a lower level FPGA driver layer 650. It issometimes referred to simply as the analyzer. The analyzer applicationlayer 630 is a hardware independent layer that is mainly responsible forcommunication with the BLL 410 via the message passing service 562. Itabstracts the interface to the FPGA driver 650, which is the lower layercomponent of the analyzer daemon. It is a hardware dependent layer thatis mainly responsible for translating configuration and statisticsretrieval requests from the application layer into hardware specificoperations. It is also responsible for extending 32-bit hardwarecounters into 64-bit database counters. The analyzer and FPGA 675controls the hardware based, line rate capable receive packet analysisfunctionality.

FIG. 6 is a high level presentation of the analyzer daemon and itsrelationship with other entities that reside on the processing card. Theanalyzer daemon is configured to reflect the specific hardware that itis controlling.

The in-memory database, as will be shown in FIG. 7, is part of the statsframework. Statistics visible to the BLL 410 are stored in the in-memoryembedded database of the stats framework 640. The BLL can thus usemessages to perform SQL queries on any of the tables in the database,using either synchronous or asynchronous mechanisms. In addition, theBLL can register for asynchronous notifications of any time that a rowin the table is added, deleted, or modified. In one embodiment, thein-memory database is instantiated, along with the entire statsframework, for each port on the processing card. In this embodiment,there are multiple tables in the database for port statistics,differential service statistics (related to different types of servicerequired by various IP packets), and test stream statistics.Alternatively, there could be separate instantiations of the databasefour each port and each of the six tables. Yet alternatively, separatetables or separate instantiations of the database can be maintained forrouting packets, host packets, and layer 2/3 packets, all on a per portbasis.

The support for various statistics, maintained as columns in the table,may depend on test modules that run on the test device. In someembodiments, rather than having different sets of attributes or columnsreached test module, the database may support a single superset ofstatistics. In a test that does not use a particular column, the valuein that column may be set to zero. If this trade-off between memory andease of programming proves too taxing on memory, alternative solutionssuch as optional columns or alternative schemas that reuse attributes inthe table may be applied.

In one embodiment, a port statistics are maintained for each sampletaken. The quantity of rows depends on the sampling rate established bythe BLL 410. Typically, rate columns do not appear in this table,because a sufficient number of rows are maintained to allow computationof rates after data collection. To accommodate calculation of rates, itmay be desirable to capture one sample more than the number of requestedsamples, thereby establishing a baseline for calculation of the firstrate sample.

The differential service statistics table has rows for each type ofservice allowed for IP packets. The type of service (e.g., 0 to 255) canbe used as an index to table rows. Calculation of rates may beexplicitly enabled for the table or particular rows in the table. Thistable supports real-time rows that are sampled and recorded at apredetermined rate. This allows rates to be calculated after datacollection, thereby reducing computing overhead and table size.

The test stream statistics table contains statistics for each stream.The streams may be learned by the analyzer from the stream block 463 orby listening to received streams 473. Rows may be added to the tableduring a test as a listening process detects new test streams. Rates maybe calculated in this table either as rows are updated or in a real timedata sampling mode. In the real-time mode, rows are sampled at apredetermined rate and added to the table as they are sampled. Again,this allows calculation of rates after data collection. This table mayinclude more columns for data than the hardware collects at any giventime. In some embodiments, the hardware can only track a subset ofpotential statistics at any given time. Different subsets of statisticsmay be grouped into stream statistic groups. For counters that are notsupported in a currently enabled statistics group, the counter valueshould be set to zero.

As will be described later in this disclosure, one mechanism forcommunication between the FPGA and user space is for the FPGA to writevalues via a direct memory access (“DMA”) channel. During datacollection, it may be necessary to latch memory so that statistics ofsome counters are not updated by the FPGA as the vector of counters isread.

Returning to FIG. 6, the analyzer application layer 630 is the upperhalf of the analyzer daemon. It is responsible for interaction with theBLL 410 via messages. It validates message parameters and translatesmessages into calls to the analyzer driver 650 and the stats framework640. The application 630 populates statistics read from the driver intothe embedded in-memory database tables. It provides a consistent anduser friendly interface for the BLL 410. In one embodiment, the analyzerapplication layer is multithreaded and uses an adaptive communicationsenvironment (ACE) reactor to serialize all timer events, message eventsand signals. In that embodiment, most operations are performed under themain thread. Additional threads may be spawned by the analyzerapplication layer 630 to perform high resolution port statisticssampling, as described below.

FIG. 7 is a more detailed block diagram of interaction of the analyzerdaemon 353 with the stats framework 640. The analyzer application 630handles interaction of the analyzer daemon 353 with the stats framework640. This includes interaction with the embedded database 742. Severalinteractions are involved. The analyzer application handlesinstantiation of the stats framework objects at initialization time,such as table descriptors, rate computers, message servers and databaseinstances for ports, etc. It handles look-up and updating of countervalues within a row on behalf of the rate computers. It configures therate computers in compliance with messages from the BLL. It modifiesdatabase entries as directed by messages. For instance, it clears rows,deletes rows or makes sure the rows are up-to-date. The analyzerapplication modifies the database entries per driver maintenancerequirements. For instance, it has streams and makes sure that streamsare up-to-date, as they change over the course of a test. It handsmessages off to the message server, which in turn instantiates andutilizes other stats framework objects. It also performs SQL queries onthe database, as necessary.

Components of the stats framework 640 include notifiers 733, messageadapters 741, the rate computer 735 and the database instantiations 742.The analyzer application 630 includes message handlers for configuration731 and queries 1 732. It also includes a row updater 734. The querymessage handler 732 interacts with the stat frame 640 through thenotifiers 733 and the message adapters 741. The configuration messagehandler interacts with the stats framework 640 and the driver layer 650.It interacts with the framework through the rate computer 735. Theanalyzer application 630, rate computer 735 and message adapter 741interact with the database instances 742.

The PortSampler object has a message queue so that: 1) the SamplerThread can initiate method calls on the PortSampler object which areexecuted within the context of the main thread; and 2) the main threadcan defer method calls on the PortSampler object until after the Start()Stop( ) methods have returned (ex. in order to send async notificationsto the BLL after the response to a Start/Stop PHX-RPC message has beenreturned). The entries on this message queue are simply functors. Uponinstantiation, the PortSampler associates a notification strategy withthe message queue such that any push onto this queue schedules an eventin the main thread's Reactor, for which the PortSampler has registereditself as a handler. In the handler method, the PortSampler simply popsthe functors from the message queue and executes them.

FIG. 8 is a block diagram that provides more detail of one embodiment ofthe analyzer driver. The analyzer driver 650 is the bottom half of theanalyzer daemon 353. It is responsible for interaction with the analyzerFPGA, abstracting FPGA implementation so that the analyzer daemon neednot be aware of module-specific variations, extending 32-bit FPGAcounters to 64-bit values, and performing counter maintenance to avoidwraparound on 32-bit FPGA counters. The analyzer driver runs in userspace 610. With assistance from the hardware extraction layer 655, itmaps to FPGA registers into the analyzer daemon 353 memory space anduses direct memory access (DMA) to retrieve counters maintained by theFPGA. In one embodiment, the driver is instantiated on a driver-per-portbasis.

One feature illustrated in the figure is to translate incremental countsinto cumulative counts. That is, when the FPGA counters provide a deltacount since the last read, the driver adds that delta count to aprevious cumulative counter. To provide current cumulative counters tothe application layer, the driver needs to have access to the previouscounter total values. In most cases, rather than rely on the applicationlayer to retrieve these values from the database, which would create arisk of the driver being blocked if another thread is holding thedatabases transaction lock, the analyzer driver 650 caches a copy of thelast counter values using non-database structures 823, 829. This isparticularly useful during high-resolution sampling with millisecondresolution.

Since multiple threads may attempt to get current counterssimultaneously, each type of counter (for instance or statisticsdifferential service statistics, etc.) has a pthread mutex 821, 827, 833associated with it. This protects the integrity of a given counter typewhile still allowing concurrent access to different counter types. Forinstance, a thread accessing port statistics will not be blocked byanother thread accessing differential service statistics. Even thoughcounters for streams sampled at normal resolution are not cached in thedriver, there still is a mutex associated with stream operations toprotect other stream related information in hardware accesses.

The maintenance thread builds on the Adaptive Communications Environmentactive object pattern. The lifetime of the maintenance thread is equalto the lifetime of the process, as it is spawned when the driver iscreated and joined when the driver is destroyed. Each type of statisticrequires maintenance as its own timeout handler that is scheduled forperiodic callbacks from a timer in the context of the maintenancethread. The exception to this is for test stream statistics, asexplained below. The period between timeouts depends on the handlertype, as well as test module type. This design allows maintenance tooccur only as frequently as necessary for each data type. Operation ofthe port driver in the context of the maintenance thread minimizes thelikelihood that maintenance will be blocked by something that the mainthread is doing, such as large SQL queries. Large SQL queries have noeffect on maintenance, except during stream maintenance, when the streamcounter maintenance includes reading current cumulative counters fromthe database. Using the pthread model, the maintenance thread consumesno CPU time unless it is actively updating some counters.

Since FPGA counters can only be updated from incoming packets while in a“running” state, there is no need to prevent counter rollover while itis in the “stopped” state. Therefore, the analyzer driver unschedulesthe maintenance timers whenever a stop command is received andreschedules them when a start command is received. Consequentially, themaintenance thread consumes no CPU when the analyzer is stopped.

Some of the FPGA functionality requires the Analyzer Driver to DMAinformation to/from the FPGA. The Analyzer Driver uses one of the DMAData Movers that are part of the BCM1125 to do this. This single datamover is shared by the threads within the Analyzer. Thus, a semaphore833 is used to protect access to DMA operations 835.

An independent HAL 655 DMA object is allocated for each of these,per-port. For each object, the HAL must allocate and map contiguouspages of RAM to support the largest DMA for which each object will beused.

FIG. 9 is more detailed block diagram of the Stats Framework. TheeXtremeDB in-memory database requires a significant framework andadapters for implementation, as this figure depicts. The underlyingdatabase components are in the right-hand columns of the figure (917,937, 967, 938, 948, 958). Most of the remaining components are part ofthe stats framework, except the message passing system 562, and theapplication and driver layers of the analyzer daemon 630/650.

The underlying database components include two APIs: a proprietary APIin fixed 917 and variable 937 parts and a SQL API 967. The proprietaryfixed API 917 is for table independent operations, such as create,commit, etc. The proprietary variable API 937 is automatically generatedfrom schema files and is for table dependent operations, such as create,find row, get or set column value. The proprietary API in general isused for updating tables as the statistics change. The SQL API is usedmainly for running queries received from the BLL 410 via the messagepassing system 562. This API supports much of the SQL-89 specification.A database instantiation exists within the address space of the processthat created. A Database Management component 913 in the stats frameworkis responsible for handling generic database-related configuration andmaintenance tasks and also for acting as a central point for accessingframework objects. It instantiates a single, independent database perport, as is reflected by the “statsdbX” (938, 948, 958) components inthe drawing.

Remote procedure call (RPC) messages from the message passing system areoffloaded by a Message Server for statistics-related messages 562. TheMessage Server executes queries on the database as specified by the RPCmessages and returns the result set to the caller. Additionally, at therequest of RPC messages, it may configure the Periodic Query Executerand Table Observer 955 to either: periodically execute queries on thedatabase and return the result set to the caller each time; or sendperiodic notifications to the caller regarding changes that have beenmade to the contents of the database.

An RPC Message to Database SQL API Adapter 965 component is used to takethe SQL query string that is contained in an RPC message and call theproper functions in the database's SQL API in order to execute thatquery. It then takes the database objects representing the result set ofthe query and parses their contents into a format suitable to becontained in an RPC message response.

A Generic Table Descriptor to Table Specific API Adapter 935 componentis used to translate general database operations that some statsframework components need to perform on database tables into thespecific database API functions that perform those operations. This isdone so that the stats framework components can remain generic, and thusoperate on any database table, yet are still capable of performing thoseoperations which require specific knowledge of the schema of the tablesbeing operated on.

A Periodic Rate Computer 932 component periodically reads configuredcounter column values from the database tables, computes a “per second”rate for these counters, and updates corresponding rate column values inthe given database table. Use of the stats framework involves severalsteps. First, create a database schema file. Appropriately modify aschema constructor script. Configure the database factory. Implement themessage set. Offload messages from the message processing system.Optionally, configure the rate computer. Also optionally, enable tableevent notifications. Then, proceed with populating the tables. Withthese steps and the framework detailed by FIGS. 7-8 in mind, one canunderstand how an in-memory database can be used in a test device.

Next, we provide some examples of real time data access that is enabledby the disclosed stats framework. These examples show how relevantstatistics can be retrieved during a test, taking advantage ofdistributed processing of SQL queries by the independent databaseinstantiations running on the processing cards. Keep in mind that aquery that may find its answer in more than one database instantiationis passed to all of the relevant database instantiations and the resultsreturned are combined. The first example shows retrieving only the“page” worth of streams that the user is currently looking at, ratherthan pulling back all streams and only displaying the ones on thecurrent page:

SELECT StreamIndex, FrameCount, SigCount, FCSErrCount, MinXFerDelay,MaxXFerDelay, SeqRunLength, LostPacketCount, InOrderPacketCount,ReorderedPacketCount, DuplicatePacketCount, LatePacketCount,PRBSBitErrCount, PRBSFillByteCount, IPv4XSumErrCount,TCPUDPXSumErrCount, FrameRate, SigRate, FCSErrRate, LostPacketRate,InOrderPacketRate, ReorderedPacketRate, DuplicatePacketRate,LatePacketRate, PRBSBitErrRate, IPv4XSumErrRate, TCPUDPXSumErrRate,Comp32, Comp16_(—)1, Comp16_(—)2, Comp16_(—)3, Comp16_(—)4, InSeqCount,TotalXFerDelay, TotalJitter, TotalInterArrivalTime, ByteRate,StreamIndex FROM StreamStats WHERE StreamIndex BETWEEN 25 AND 49

A sample response showing the contents of one of the rows that matchesthe criteria is:

“int64Values” {array {int64_t 25 int64_t 144 int64_t 144 int64_t 0int64_t 9 int64_t 10 int64_t 144 int64_t 0 int64_t 144 int64_t 0 int64_t0 int64_t 0 int64_t 0 int64_t 0 int64_t 0 int64_t 0 int64_t 0 int64_t 0int64_t 0 int64_t 0 int64_t 0 int64_t 0 int64_t 0 int64_t 0 int64_t 0int64_t 0 int64_t 0 int64_t 65561 int64_t 0 int64_t 0 int64_t 0 int64_t0 int64_t 0 int64_t 1435 int64_t 0 int64_t 0 int64_t 0 int64_t 25 } }

Subsequent pages of streams data are retrieved on demand.

The next example shows retrieving the summation of stats of streams thatare in an associated group (in this case the summation of the streams ina given stream block), rather than pulling back all streams in the groupand aggregating the counters in the BLL:

SELECT SUM(FrameCount), SUM(ByteRate)

FROM StreamStats

WHERE StreamIndex BETWEEN 3 AND 102

A response includes one row, since it aggregates many rows:

“int64Values” {array {int64_t 4120 int64_t 0}}

Using this approach, message traffic is greatly reduced. In alllikelihood, resources required data reduction on the processing cardsare more than offset by the reduced message traffic.

Another example shows retrieving streams that meet a user-generatedquery (in this case only the top 50 streams, displayed in order ofincreasing maximum latency, where more than 50000 packets have beenreceived and the maximum latency is greater than 50 ms.) Again, thedatabase instances reduce the data before messaging, rather than pullingback all streams and displaying only the ones that meet the criteria:

 SELECT StreamIndex, FrameCount, SigCount, FCSErrCount, MinXFerDelay,MaxXFerDelay, SeqRunLength, LostPacketCount, InOrderPacketCount,ReorderedPacketCount, DuplicatePacketCount, LatePacketCount,PRBSBitErrCount, PRBSFillByteCount, IPv4XSumErrCount,TCPUDPXSumErrCount, FrameRate, SigRate, FCSErrRate, LostPacketRate,InOrderPacketRate, ReorderedPacketRate, DuplicatePacketRate,LatePacketRate, PRBSBitErrRate, PRBSFillByteRate, IPv4XSumErrRate,TCPUDPXSumErrRate, Comp32, Comp16_1, Comp16_2, Comp16_3, Comp16_4,InSeqCount, TotalXFerDelay, TotalJitter, TotalInterArrivalTime, ByteRateFROM StreamStats WHERE (FrameCount > 50000) AND (MaxXFerDelay > 5000)ORDER BY MaxXFerDelay ASC LIMIT 50

A sample response showing the contents of one of the rows that matchesthe criteria is:

“int64Values” {array {int64_t 51 int64_t 65225 int64_t 65225 int64_t 0int64_t 253 int64_t 6341 int64_t 65225 int64_t 0 int64_t 65225 int64_t 0int64_t 0 int64_t 0 int64_t 0 int64_t 0 int64_t 0 int64_t 0 int64_t 0int64_t 0 int64_t 0 int64_t 0 int64_t 0 int64_t 0 int64_t 0 int64_t 0int64_t 0 int64_t 0 int64_t 0 int64_t 0 int64_t 65587 int64_t 0 int64_t0 int64_t 0 int64_t 0 int64_t 0 int64_t 26210000 int64_t 0 int64_t 0int64_t 0 } }

The corresponding end of test queries are very broad. In addition to thequery examples, we provide a few rows of returned data and correspondingtranslation of the returned data directly into add-row commands for thepersistent database 515.

SELECT StreamIndex, Comp32, Comp16_1, Comp16_2, Comp16_3, Comp16_4,FrameCount, ByteCount, SigCount, FCSErrCount, AvgXFerDelay,MinXFerDelay, MaxXFerDelay, TotalXFerDelay, SeqRunLength,ExpectedSeqNum, LostPacketCount, InOrderPacketCount,ReorderedPacketCount, DuplicatePacketCount, LatePacketCount,MinFrameLength, MaxFrameLength, PRBSFillByteCount, PRBSBitErrCount,IPv4XSumErrCount, TCPUDPXSumErrCount FROM StreamStats WHERE StreamIndexBETWEEN 0 AND 8191 AND FrameCount > 0Additional blocks of data can be collected in a succession query (orcould be part of the initial query);

SELECT StreamIndex, Comp32, Comp16_1, Comp16_2, Comp16_3, Comp16_4,FrameCount, ByteCount, SigCount, FCSErrCount, AvgXFerDelay,MinXFerDelay, MaxXFerDelay, TotalXFerDelay, SeqRunLength,ExpectedSeqNum, LostPacketCount, InOrderPacketCount,ReorderedPacketCount, DuplicatePacketCount, LatePacketCount,MinFrameLength, MaxFrameLength, PRBSFillByteCount, PRBSBitErrCount,IPv4XSumErrCount, TCPUDPXSumErrCount FROM StreamStats WHERE StreamIndexBETWEEN 8192 AND 16383 AND FrameCount > 0Here is a sample row of response data:

“int64Values” { array { int64_t 0 int64_t 131072 int64_t 0 int64_t 0int64_t 0 int64_t 0 int64_t 146997 int64_t 18815616 int64_t 146997int64_t 0 int64_t 10 int64_t 10 int64_t 11 int64_t 1489447 int64_t146997 int64_t 146997 int64_t 0 int64_t 146997 int64_t 0 int64_t 0int64_t 0 int64_t 128 int64_t 128 int64_t 0 int64_t 0 int64_t 0 int64_t0 } }

Some Particular Embodiments

The technology disclosed can be practiced as a device or a method theruns on a device. The technology disclosed may be practiced as anarticle of manufacture such as storage media impressed with logic.

One embodiment is a device reporting results from testing of a systemunder test or device under test, which are collectively referred to as a“DUT”. The test device includes a least one chassis and a plurality ofprocessing cards mounted in the chassis. Multiple chassis can becombined into a single system, using inter-chassis communications. Achassis could hold a single processing card, but it preferably holdsmultiple cards. In one embodiment, a chassis holds a dozen cards.Alternatively to a chassis, a conventional server, workstation or PCcould be fitted with processing cards. The chassis is more versatile,because its form factor can accommodate exposure of more ports thanwould fit on a typical PCI card. A processing card integrates at least aprocessor, solid-state memory coupled in communication with theprocessor, and two or more test ports coupled in communication with theprocessor that are adapted to be coupled to the DUT during a test. Avariety of test ports, many of which are identified above, may be used.In some configurations a dozen test ports are found on a singleprocessing card.

Ports may optionally be organized into port groups. For instance, in oneembodiment, a twelve port processing card includes six processors. Theprocessors are separate chips. The processors run their own instances ofLinux and control two ports. The processing card includes six portgroups, each group sharing processing and memory resources among one ormore ports (two ports in this example). In another embodiment, a singlehigh speed port (10⁺ Gb) is coupled to a Linux instance and multipleprocessor cores. The single high speed port is a port group of one,because of the resources needed to service the port. In the architecturedescribed, it is readily practical to include up to eight ports in agroup, which may be useful when multiple ports are being aggregated intoa single communications channel. When we use the term “port group,” werefer to a group of ports commonly controlled by shared hardware andsoftware resources. A port group may include one to eight ports,depending on how the supporting hardware and software resources areorganized.

The device further includes distributed logic running on the processingcards. The distributed logic includes a plurality of database instancesat least one per port or port group. A particular database instanceincludes at least a unique identifier that distinguishes it from otherdatabase instances for messaging, such as receiving queries. Thedatabase instance includes one or more tables of sample data collectedduring the test, the tables residing in the solid-state memory on theprocessing card. Optionally, if a pooled memory space were available,the database instances could share the pooled memory space. Solid-statememory is specified to avoid the latencies of rotating memory that areexperienced during database access and transaction locking A particulardatabase further includes two interfaces: an API interface that updatesand adds to the tables during the test; and a query processinginterface. The query processing interface can be used either during orafter the test. It receives queries, for instance, SQL queries. Itselects the sample data responses to the queries and returns theselected sample data. The device further includes at least onecommunications channel on the chassis coupled in communication with thedistributed logic. This communications channel distributes the queries,both queries from users and automatic, end-of-test queries. Thecommunications channel returns the selected sample data responsive tothe queries.

In some embodiments, the processing cards further include a specializedlogic device to processes test frame data to send to or to receive fromthe DUT during the test. The specialized logic device is coupled incommunication between the processor and the ports. It updates countersduring the test frame data processing. The distributed logicperiodically collects the sample data from the counters and adds thesample data to the tables or updates the tables via the API interface.

In one variation, the port groups are supported by a plurality ofprotocol handling modules running on the processing cards that support amultiplicity of devices in device-sessions. In this variation, thedevice further includes database instances per port group per protocolhandling module, whereby different sample data statistics applicable todifferent protocols are stored in different database instances.Alternatively, a single database per port group may have separate tablesfor various protocol handling modules. These separate tables allowdifferent sample data statistics applicable to different protocolsources to be stored in separate tables.

In another variation, the test is organized into a plurality of testdata streams emulate a multiplicity of data sessions. Device furtherincludes database instances per port per data test string.Alternatively, a single database per port group may have a table for alldata streams that interact with that port. A data stream identifier canbe attached to each row in the data streams table. In yet anotheralternative, the ports emulate a plurality of sessions and a pluralityof protocols in the sessions. In this other alternative, databaseinstances are running per port group per test data stream per protocol.

In any of the particular embodiments described, the query processinginterface may be SQL compatible. Anywhere these port groups arespecified as the unit of database organization, single port databasescan be used.

The test device embodiment can be extended into a system for real-timedata collection. The real-time system further includes management logicrunning on at least one additional processor that is coupled to thecommunications channel. This additional processor may be on a separatesystem, integrated into the chassis, or hosted on a chassis card. Themanagement logic of this real-time system includes at least a userinterface, such as a scripting command line or GUI interface, throughwhich a user requests are received. It includes a data selectioncomponent or module that translates the user requests into queries forresponsive sample data. It further includes a messaging component ormodule that identifies a plurality of database instances to which thequery should be directed, that sends the queries the identified databaseinstances without waiting for responses before sending successivequeries to successive database instances, and receives responses fromthe identified database instances as they become available. A responseaggregation component or module combines the selected sample data fromthe responses. This combined data may be aggregated into a collection,summed or otherwise reduced into a desired form. An output component ormodule either persists the combined data to nonvolatile memory or makesthe combined data perceptible to the user.

Alternatively, the test device embodiment can be extended into a systemfor end-of-test data collection. Of course, the real-time datacollection and end of test data collection systems are compatible andmay be combined into an overall system. In the end-of-test datacollection system, management logic running on an additional processorand coupled to the communications channel and persistent memory includesa least a data collection component or module issues queries for returnof substantially all of the sample data collected by the databaseinstances for at least one segment of the test or, preferably, for thewhole test. The data collection module preferably sends successivequeries to successive database instances without waiting for completionof query responses. It receives responses from the identified databaseinstances as they become available. The management logic furtherincludes persistent memory coupled in communication with the additionalprocessor and at least one persistent database component or module thatmaintains a persistent test result database on the persistent memory.The system further includes at least one data translation module thattranslates the responses directly into update commands and queues theupdate commands to the persistent database module without waiting for anupdate confirmations before issuing successive update commands.

The device embodiments above have method counterparts. One methodembodiment provides real time results from testing of a system undertest or device under test, which are collectively referred to as a“DUT.” One environment in which it is useful is a test device thatincludes at least one chassis and a plurality of processing cardsmounted in the chassis. Multiple chassis can be combined into a singlesystem, using inter-chassis communications. A chassis could hold asingle processing card, but it preferably holds multiple cards. In oneembodiment, a chassis holds a dozen cards. Alternatively to a chassis, aconventional server, workstation or PC could be fitted with processingcards. The chassis is more versatile, because its form factor canaccommodate exposure of more ports than would fit on a typical PCI card.A processing card integrates at least a processor, solid-state memorycoupled in communication with the processor, and two or more test portscoupled in communication with the processor that are adapted to becoupled to the DUT during a test. A variety of test ports, many of whichare identified above, may be used. In some configurations a dozen testports are found on a single processing card.

The method itself includes instantiating a plurality of databaseinstances, at least one per port group, and associating them with ports.A particular database instance includes at least a unique identifierthat distinguishes it from other database instances for messaging, suchas receiving queries. The database instance includes one or more tablesof sample data collected during the test, the tables residing in thesolid-state memory on the processing card. Optionally, if a pooledmemory space were available, the database instances could share thepooled memory space. Solid-state memory is specified to avoid thelatencies of rotating memory that are experienced during database accessand transaction locking A particular database further includes twointerfaces: an API interface that updates and adds to the tables duringthe test; and a query processing interface. The query processinginterface can be used either during or after the test. It receivesqueries, for instance, SQL queries. It selects the sample data responsesto the queries and returns the selected sample data. The method furtherautomatically retrieving sample data related to the associated portsduring the test and using the API interfaces to add the retrieved sampledata to the tables. The method further includes receiving at a pluralityof the database instance at least one query via the query processinginterfaces, selecting the sample data responsive to the query, andreturning the selected sample data during or after the test.

In some embodiments, the processing cards further include a specializedlogic device to process test frame data to send to or to receive fromthe DUT during the test. The specialized logic device is coupled incommunication between the processor and the ports. It updates countersduring the test frame data processing. The method further includesperiodically collecting the sample data from the counters and adds thesample data to the tables or updates the tables via the API interface.

In variations on the number of databases instantiated, any of theorganizations described with respect to the device embodiments also maybe applied to the method embodiments. Moreover, the query received atthe database instance may be SQL compatible.

The method embodiment can be extended into a method for real-time datacollection. The real-time method further includes receiving a userrequest during a test at a user interface, such as a scripting, commandline or GUI interface. The user request is translated into queries forresponsive data, which are sent to identified database instances.Preferably, the queries are sent the identified database instanceswithout waiting for responses before sending successive queries tosuccessive database instances, and receives responses from theidentified database instances as they become available. Alternatively,the queries could be issued sequentially and processed synchronously.The method includes receiving responses and combining the selectedsample data from the responses. This combined data may be aggregatedinto a collection, summed or otherwise reduced into a desired form. Themethod proceeds by either persisting the combined data to nonvolatilememory or makes the combined data perceptible to the user.

Alternatively, the method embodiment can be extended into a method forend-of-test data collection. Of course, the real-time data collectionand end-of-test data collection methods are compatible and may becombined into an overall system. In the end-of-test data collectionmethod, queries are issued for return of substantially all of the sampledata collected by the database instances for at least one segment of thetest or, preferably, for the whole test. Queries to successive databaseinstances may be issued without waiting for completion of queryresponses or they could be issued sequentially and processedsynchronously. Responses from the identified database instances arereceived as they become available. The method further includes queuingupdate commands to a persistent database module. As with the requests,these update commands can be sent the database module without waitingfor update confirmations or they can be handled sequentially andsynchronously.

Articles of manufacture are alternative embodiments. The devices for andmethod of providing real time data collection and the extended methodsof providing real time and end-of-test results are all practiced ascomputer readable storage media including program instructions that,when loaded on appropriate hardware, either produce one of the devicesdescribed or carry out one of the methods described.

Another method involves transmitting programs of computer instructionsto be combined with appropriate hardware to manufacture one of thedevices described.

While the present invention is disclosed by reference to the preferredembodiments and examples detailed above, it is understood that theseexamples are intended in an illustrative rather than in a limitingsense. Computer-assisted processing is implicated in the describedembodiments. Accordingly, the present invention may be embodied inmethods for generating test frames, systems including logic andresources to carry out automated generation of test frames, computerreadable storage media impressed with logic to carry out automatedgeneration of test frames, or a method of delivering data streamsimpressed with logic to carry out automated generation of test frames.It is contemplated that modifications and combinations will readilyoccur to those skilled in the art, which modifications and combinationswill be within the spirit of the invention and the scope of thefollowing claims.

We claim as follows:
 1. A real time data collection monitoring systemreporting results from a multiplicity of streams, the monitoring systemincluding: at least one management processor with memory; a plurality ofdistributed processors with memory and monitored ports or port groups,wherein the distributed processors are coupled in communication with themanagement processor; distributed logic running on the distributedprocessors that includes a plurality of database instances, at least oneper port or port group, wherein said database instances include atleast: one or more tables of monitoring data collected from themonitored ports or port groups during a sampling period, the tablesresiding in the memory coupled to the distributed processors, an APIinterface that updates and adds to the tables during the samplingperiod, and a query processing interface that receives queries, selectsthe monitoring data responsive to the queries, and returns the selectedmonitoring data during and after the sampling period; and managementlogic running on the management processor coupled in communication withthe distributed logic that distributes the queries to the distributedprocessors.
 2. The system of claim 1, wherein the distributed processorsfurther include a specialized logic that processes test frame data tosend to or received from testing a system or device under test (referredto as a “DUT”), during the sampling period and updates counters duringthe test frame data processing, the specialized logic coupled incommunication with the ports, and the distributed logic periodicallycollects the monitoring data from the counters and adds the monitoringdata to the tables via the API interface.
 3. The system of claim 1,wherein the query processing interface is SQL compatible.
 4. The systemof claim 1, wherein the ports or port groups are supported by aplurality of protocol handling modules running on the distributedprocessors that emulate a multiplicity of devices in device-sessions,further including database instances per port group per protocolhandling module, whereby different sample data statistics applicable todifferent protocols are stored in different database instances.
 5. Anend of sapling period data collection system including the system ofclaim 1, wherein the management logic further comprises: a datacollection module that issues queries for return of substantially all ofthe monitoring data collected by the database instances for at least onesegment of the sampling period without waiting for query responsesbefore sending successive queries to successive database instances, andreceives responses from the database instances as they become available;and at least one persistent database module coupled to the datacollection module that maintains a persistent monitoring resultdatabase.
 6. A method of providing real time data collection andmonitoring, the method including: instantiating a plurality of databaseinstances, at least one per port group of monitored ports, andassociating them with the monitored ports, wherein said databaseinstances comprise at least: one or more tables of monitoring datacollected during a sampling period, the tables residing in memorycoupled to a processor, an API interface that updates and adds to thetables during the sampling period, and a query processing interface thatreceives queries, selects the monitoring data responsive to the queries,and returns the selected monitoring data during and after the samplingperiod; and automatically retrieving monitoring data from the associatedports during the sampling period and using the API interfaces to thedatabase instances to add the retrieved monitoring data to the tables.7. The method of claim 6, further including receiving at a plurality ofthe database instances at least one query via the query processinginterfaces, selecting the monitoring data responsive to the query, andreturning the selected monitoring data during or after the samplingperiod.
 8. The method of claim 6, further including instantiating aplurality of protocol handling objects for a plurality of the ports orport groups, wherein the instantiation of the database instances furtherincludes instantiating database instances per port or port group and perprotocol handling object, whereby different sample data statisticsapplicable to different protocols are stored in different databaseinstances.
 9. A real time monitored data reporting method, including themethod of claim 6, further including: receiving a user request via auser interface; translating the user request into the queries forresponsive monitoring data; identifying a plurality of the databaseinstances to which the queries should be directed; sending the queriesto the identified database instances without waiting for responsesbefore sending successive queries to successive database instances;receiving responses from the identified database instances as theybecome available; and combining the selected monitoring data from theresponses and either persisting the combined data or making itperceptible to the user.
 10. An end of sampling period data reportingmethod, including the method of claim 6, further including: issuingqueries from a data collection module for return of substantially all ofthe monitoring data collected by the database instances during thesampling period without waiting for query responses before sendingsuccessive queries to successive database instances; receiving responsesfrom the database instances as they become available; translating theresponses directly into update commands; and queuing the update commandsto a persistent database module without waiting for update confirmationsbefore issuing successive update commands.